∂28-Feb-77  1204	FTP:LEFAIVRE at RUTGERS-10	NEWEST COMPILER   
Date: 28 Feb 1977 (Monday) 1503-Est
From: LEFAIVRE at RUTGERS-10
Subject: NEWEST COMPILER
To:   DIFFIE at SU-AI

Whit-

I recently found another obscure bug in the compiler, making the version
you have obsolete already (!).  The corrected version is in LSP:ILISPC.LSP.
Note that I have finally released the entire RUTGERS/UCI LISP system,
including ILISP itself (with the new prettyprinter, lots of new functions,
↑C interrupt routine, etc.), ILISPC (with bug fixes, in-line ERRSETs, etc.),
and ILISP versions of PLNR, FUZZY, and CNVR (CNVR not quite ready yet).
All of the new stuff (including new features of the compiler) is described in
LSP:ILISP.MAN, which should magically appear in about an hour (I am making
some final editing changes).  I don't know if you have a locally-hacked
UCI LISP out there or what, but you might want to look at RUTGERS/UCI LISP
for use at Stanford.  If you do, send me a tape and I'll copy the LSP:
library onto it.

-Rick


∂15-Mar-77  1913	FTP:LEFAIVRE at RUTGERS-10	YET ANOTHER COMPILER BUG    
Date: 15 Mar 1977 (Tuesday) 2214-Est
From: LEFAIVRE at RUTGERS-10
Subject: YET ANOTHER COMPILER BUG
To:   DIFFIE at SU-AI

Whit-

My new version of the compiler is now affectionately (?) known at
Rutgers as the "BUGLESS COMPILER" because of the assurances I keep
giving people that I've finally (underlined) found the LAST BUG!
Well, another one turned up last weekend.  Its good that the system
is now officially released, as more people are giving it a workout.
Following this message is a new version of the compiler, followed
by an updated CTEST (the latest bug is RB9).  I think it's easier
to just send the whole thing over this way instead of sending the
changes and having you incorporate them in your version.

-Rick

∂28-Jul-77  1752	FTP:LEFAIVRE at RUTGERS-10	Another ILISPC bug bites the dust
Date: 28 Jul 1977 (Thursday) 2050-Est
From: LEFAIVRE at RUTGERS-10
Subject: Another ILISPC bug bites the dust
To:   DIFFIE at SU-AI

Whit-

Just discovered another bug in the compiler I sent you a while ago.  As
this one was of my own doing, I feel especially obligated to let you know
about it.  It came about because I moved the old GUARDLOCS code and the
CLEAR1 inside of P2COND1, so it could be called both by P2COND and BOOLCOND.
In so doing, I inadvertantly masked out P2PROG's copy of MINDEPTH, so that
if a CLRPVARS is delayed until after a COND is entered, it is possible for
the stack to be popped too far.  This bug has been in for about a year, and
it only made itself known today, so it is rather rare.  My fix was to split
P2COND1 into two PROGs, with the second binding MINDEPTH after the CLEAR1 is
done in the first.

We also discovered that if a special var has the same name as a function
and it is called before the function is defined or declared, the call is
compiled as a variable (as one would expect).  However, the user is not
warned about this when the function is finally defined.  I put a check in
for this, along with a couple of other little fixes.

If you still have plans to use this compiler, I will be happy to FTP it
over (or send me a tape and you can have the whole super RUTGERS/UCI LISP
system - it's now spreading to other TOPS installations around the country).

-Rick


∂05-Nov-77  0624	FTP:LEFAIVRE at RUTGERS-10 	YET ANOTHER COMPILER BUG   
Date:  5 Nov 1977 (Saturday) 0921-Est
From: LEFAIVRE at RUTGERS-10
Subject: YET ANOTHER COMPILER BUG
To:   DIFFIE at SU-AI

Whit-

Cris Perdue at CMU uncovered another bug in the LISP compiler.  The simplest
manisfestation seems to be a function like:

	(DE TST (X) (FUNC (CAR X) (FUNC2 (CAR (CAR X)))))

The problem is that when CSTEP goes to load the first CAR, COPT tells it
that it is equivalent to the second and needn't be recomputed.  This
association is established via VARLIST.  But when CSFUN is called to
clear the first CAR off of CCLST, it calls ILOC instead of ILOC1, and
ILOC doesn't check VARLIST, so another call to LOADCARCDR is made.
Since the second CAR has already been loaded and REMOVEd, LOADCARCDR
decides it must reload the CAR, but X is long gone and . . . BANG.

I don't know if this bug has been around for awhile or not.  None of
my fixes affected this stuff directly, but some other fix might have
impacted on it.  Anyway, the fix appears to be to change CSFUN to call
ILOC1 instead of ILOC:

	(DFUNC (CSFUN L AC)
	 (PROG (Y) (AND (SETQ Y (ASSOC (CAR L) LDLST)) (ILOC1 Y AC))))

(The LOADCARCDR in CSFUN is now done by ILOC1 if necessary).

I've also decided to fix a problem with the in-line MAP functions.  The
interpreter takes the CDR BEFORE it applies the function, so if the
function does a RPLACD things are ok.  The compiled code tries to take
the CDR AFTER the function application, so a RPLACD screws things up.
I'm going to fix the compiler to do it the way the interpreter does.
While I'm at it I'm going to change MAPCAR, MAPLIST, MAPCONC, and
MAPCON to use TCONC and LCONC instead of doing it all in-line - should
save some space.

There is a growing effort to try and standardize Stanford/UCI/Rutgers
LISP as the major LISP after INTERLISP and MACLISP, headed by Jim
Meehan at UCI, Cris Perdue at CMU, and myself.  We are discussing
such controversial topics as just what should be in the system and what
should be in library packages, and how we can work jointly on a comprehensive
manual.  Would you (or someone else there) have any interest in joining
such an effort?


∂20-Nov-77  1816	FTP:LEFAIVRE at RUTGERS-10 	Another compiler bug  
Date: 20 Nov 1977 (Sunday) 2114-Est
From: LEFAIVRE at RUTGERS-10
Subject: Another compiler bug
To:   DIFFIE at SU-AI, CRIS.PERDUE at CMU-10A

I just found another bug in the LISP compiler.  It has me a little worried,
as it seems too simple to have been around for a long time, but I'm not
sure if any changes of mine over the past year caused it.  It involves
constructs like the following:

	(DE TST (X) (COND [(EQ X (SETQ X 5)) (FUNC X)]))

In my version of the compiler BOOLEQ1 gets screwed up after it evaluates
the two arguments to EQ.  The old X is sitting in the PDL and the new X
is in a register, but since a SAVEACS is done after removing the args from
LDLST, the new X is saved on top of the old X (which looks like garbage),
and the comparison always compares 5 with 5.

It took me awhile to come up with a fix, as the logic interacts heavily
with the stuff in P2COND1 which tries to insure that no permanent
pushes need to be done inside a COND.  The following seems to work:

	(COND [(AND (DVP (SLOTCONT AC))
		    (NUMBERP MEM)
		    (LESSP MEM 1))
	       (SETQ ARG1 (SLOTCONT MEM))
	       (LOADARG (SETQ MEM (FREEAC)) ARG1)])

This goes right before the SAVEACS in BOOLEQ1.  The idea is that if the
object in the AC is still important after REMOVEing it, i.e., it needs
to be saved somewhere by the SAVEACS, we should get the other arg into
an ac to make sure it isn't taking up a pdl slot into which the first
arg could be placed.

This looks like a typical kludge which could either cause some other
problems or doesn't solve the problem in all cases, but until someone
comes up with something better . . .